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PpLog is an experimental extension of logic programming with strategic conditional transformation 
rules, combining Prolog with pLog calculus. The rules perform nondeterministic transformations on 
hedges. Queries may have several results that can be explored on backtracking. Strategies provide a 
control on rule applications in a declarative way. With strategy combinators, the user can construct 
more complex strategies from simpler ones. Matching with four different kinds of variables provides 
a flexible mechanism of selecting (sub)terms during execution. We give an overview on programming 
with strategies in PpLog and demonstrate how rewriting strategies can be expressed. 

1 Introduction 

PpLog (pronounced Pe-ro-log) is an experimental tool that extends logic programming with strategic 
conditional transformation rules, combining Prolog with pLog calculus lfl4ll . pLog deals with hedges 
(sequences of terms), transforming them by conditional rules. Transformations are nondeterministic and 
may yield several results. Logic programming seems to be a suitable framework for such nondeter- 
ministic computations. Strategies provide a control on rule applications in a declarative way. Strategy 
combinators help the user to construct more complex strategies from simpler ones. Rules apply match- 
ing to the whole input hedge (or, if it is a single term, apply at the top position). Four different types 
of variables give the user flexible control on selecting subhedges in hedges (via individual and sequence 
variables) or subterms/contexts in terms (via function and context variables). As a result, the obtained 
code is usually quite short, declaratively clear, and reusable. 

PpLog programs consist of clauses. The clauses either define user-constructed strategies by (condi- 
tional) transformation rules or are ordinary Prolog clauses. Prolog code can be used freely within PpLog 
programs. One can include its predicates in PpLog rules, which is especially convenient when arithmetic 
calculations or input-output features are needed. 

PpLog inference mechanism is essentially the same as SLDNF-resolution, multiple results are gen- 
erated via backtracking, its semantics is compatible with semantics of normal logic programs [13 ] and, 
hence, Prolog was a natural choice to base PpLog on: The inference mechanism comes for free, as 
well as the built-in arithmetic and many other useful features of the Prolog language. Following Prolog, 
PpLog is also untyped, but values of sequence and context variables can be constrained by regular hedge 
or tree languages. We do not elaborate on this feature here. 

For the users familiar with logic programming and Prolog it is pretty easy to get acquainted with 
PpLog and to quickly start writing programs, since its syntax is very similar to that of Prolog and se- 
mantics is based on logic programming. 

We tried to provide as little as possible hard-wired features in the system to give the user a freedom in 
experimenting with different choices. Probably the most notable such feature is the leftmost-outermost 
term traversal strategy the Pp Log's matching algorithm uses, but it can also be easily modified since the 
corresponding Prolog code is open: Exchanging the order of clauses there would suffice. The user can 
also program different traversal strategies pretty easily inside PpLog. 
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The goal of this paper is to give an overview of PpLog and, in particular, show how it uses strategies. 
After briefly reviewing the related work in Section^ we discuss the syntax of PpLog (Section© and then 
list some of the strategies from the library together with examples that explain the input-output behavior 
of the system (Section @]). Next, we show how user-defined strategies can be introduced illustrating it on 
the examples of defining rewriting strategies in PpLog (Section [5]). One can see that the code there is 
quite short and readable, and it also demonstrates expressiveness of PpLog. 

2 Related Work 

Programming with rules has been experiencing a period of growing interest since the nineties when 
rewriting logic [ 15 ] and rewriting calculus HIH have been developed and several systems and languages 
(ASF-SDF 0, CHR QD, Claire 0, ELAN ID, Maude 0, Stratego ED, just to name a few) emerged. 
The pLog calculus has been influenced by the p -calculus EHH as also its name suggests, but there are 
some significant differences: pLog adopts logic programming semantics (clauses are first class concepts, 
rules/strategies are expressed as clauses), uses top-position matching, and employs four different kinds 
of variables. Consequently, PpLog (based on pLog) differs from ELAN (based on p-calculus). Also, 
ELAN is a mature system with a very efficient compiler while PpLog is an experimental extension of 
Prolog implemented in Prolog itself. 

From the architecture point of view, PpLog is closer to another mature system, CHR, because both 
extend the host language (in this case, Prolog) in a declarative way. However, the purpose of CHR is 
different: It has been designed as a language for writing constraint solvers. CHR extends Prolog with the 
rules to handle constraints that are the first class concept there. PpLog is not designed specifically for 
programming constraint manipulation rules and we have not experimented with specifying such rules. 

In the OBJ family of languages (OBJ2 [9], OBJ3 D3L CafeOBJ [ 10]), local strategies can be explic- 
itly specified. They guide evaluation: In function calls only the arguments, specified by the strategies 
are evaluated. Among the other systems, strategic programming is supported Maude, and Stratego. 
Maude is based on rewriting logic, can perform efficient pattern matching modulo equational theories 
like associativity, commutativity, idempotence, and has a high-performance rewrite engine. Stratego is 
a domain-specific language designed for program transformation, combining term traversal strategies, 
pattern matching, and rewriting. 

To compare with these systems, PpLog has been designed with the purpose to experiment with 
strategic conditional transformation rules in a logic programming environment. Strategies and nondeter- 
ministic computations fit well into the logic programming paradigm. Bringing hedge and context pattern 
matching and strategic transformations into logic programs seems to facilitate writing declaratively clear, 
short, and reusable code. 

3 Preliminaries 

PpLog is essentially based on the language of pLog lTT4ll . extending Prolog with it. Here we use the 
PpLog notation for this language, writing its constructs in typewriter font. The expressions are built 
over the set of functions symbols & and the sets of individual, sequence, function, and context variables. 
These sets are disjoint. PpLog uses the following conventions for the variables names: Individual vari- 
ables start with i_ (like, e.g., i_Var for a named variable or i_ for the anonymous variable), sequence 
variables start with s_, function variables start with f _, and context variables start with c_. The symbols 
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in & , except the special constant hole, have flexible arity. To denote the symbols in & ", PpLog basically 
follows the Prolog conventions for naming functors, operators, and numbers. 

Terms t and hedges h are constructed in a standard way by the following grammars: 

t ::= i_X | hole | f(h) | f_X(h) | c_X(t) 
h : := t | s_X | eps | h_l , h_2 

where eps stands for the empty hedge and is omitted whenever it appears as a subhedge of another hedge. 
a(eps) and f _X(eps) are often abbreviated as a and f _X. A Context is a term with a single occurrence 
of hole. A context can be applied to a term, replacing the hole by that term. For instance, applying the 
context f (hole , b) to g(a) gives f (g(a) , b). 

A Substitution is a mapping that maps individual variables to (hole-free) terms, sequence variables 
to (hole-free) hedges, function variables to function symbols, and context variables to contexts so that 

• all but finitely many individual, sequence, and function variables are mapped to themselves, and 

• all but finitely many context variables are mapped to themselves applied to the hole. 

The mapping is extended to arbitrary terms and hedges in the usual way. For instance, the im- 
age of the hedge (c_Ctx(i_Term) , f _Funct (s_Termsl , a, s_Terms2)) under the substitution 
{c_Ctxi— >-f (hole) , i_Termi— >g(s_X) , f _Functi— >-g, s_Termsli— >-eps , s_Terms2i— >■ (b , c)} is 
the hedge (f(g(s_X)) , g(a, b, c)). 

In lfl2l . an algorithm to solve matching equations in the language just described has been introduced. 
Matching equations are equations between two hedges, one of which does not contain variables. Such 
matching equations may have zero, one, or more (finitely many) solutions, called matching substitutions 
or matchers. 

Example 1 The term c_X(f (s_Y) ) matches g(f (a, b) , h(f (a) , f ) ) in three different ways with 
the matchers {c_Xi-^g(hole , h(f(a), f)), s_Yi-Ka, b)}, {c_Xi->g(f (a, b) , h(hole, f)), 
s_Yh^a}, and {c_Xi-^g(f (a, b) , h(f(a), hole)), s_YH-eps}. 

The hedge (s_X, f_F(i_X, a, s_) , s_Y) matches (a, f (b) , g(a, b) , h(b, a.)) with the 
matcher {s_Xi— )• (a, f (b) , g(a, b)), f _Fi — >h, i_Xi— 7>b, s_Yi— ^eps}, 

A pLog atom (p-atom) is a triple consisting of a term st (a strategy) and two hedges hi and h2, 
written as st : : hi ==> h2. (The hedges hi and h2 do not contain the hole constant.) Intuitively, it 
means that the strategy st transforms the hedge hi to the hedge h2. (We will use this, somehow sloppy, 
but intuitively clear wording in this paper.) Its negation is written as st : : hi =\=> h2. A pLog 
literal (p-literal) is a p-atom or its negation. A PpLog clause is either a Prolog clause, or a clause of the 
form st : : hi ==> h2 : - body (in the sequel called a p-clause) where body is a (possibly empty) 
conjunction of p- and Prolog literals 

A PpLog program is a sequence of PpLog clauses and a query is a conjunction of p- and Prolog 
literals. A restriction on variable occurrence is imposed on clauses: If a p-clause has the body that 
contains Prolog literals, then the only variables that can occur in those Prolog literals are the pLog 
individual variables. (When it comes to evaluating such Prolog literals, the individual variables there are 
converted into Prolog variables.) The same restriction applies to p -queries where Prolog literals occur. 
On the other hand, Prolog clauses can not contain any pLog variables. In short: p-clauses and queries 
can contain only pLog variables. Prolog clauses and queries can contain only Prolog variables. 

'in fact, PpLog clauses may have a more complex structure, when (some of) the literals are equipped with membership 
constraints, constraining possible values of sequence and context variables. Such constraints are taken into account in the 
matching process. For simplicity, we do not consider them in this paper. 
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Both a program clause and a query should satisfy a syntactic restriction, called well-modedness, 
to guarantee that each execution step is performed using matching (which is finitary in our language) 
and not unification (whose decidability is not known. It subsumes context unification whose decid- 
ability is a long-standing open problem ITU.)- To explain the essence of the problem, consider a query 
str :: (i_X, i_X) ==> i_X. It contains (two copies of) a variable in the left-hand side, which might 
give rise to an arbitrarily complex context unification problem t\ = ? ti, if there is a clause with the head 
of the form str : : (t\, t<i) ==> h and t\ and ?2 are terms containing context variables. It can be that 
the unification problem has infinitely many unifiers (this might be the case also with sequence variables), 
which leads to computing infinitely many answers. Even worse, since the decision algorithm for context 
unification is not known, an attempt to compute context unifiers might run forever without detecting that 
there are no more unifiers. 

All these cases are extremely undesirable from the computational point of view. Therefore, we would 
like to restrict ourselves to the fragment that guarantees a terminating finitary solving procedure. Match- 
ing is one of such possible fragments. Well-moded clauses and queries forbid uninstantiated variables to 
appear in one of the sides of unification problems and, hence, allow only matching problems. Queries 
like str :: (i_X, i_X) ==> i_X above and clauses that might lead to such kind of queries are not 
allowed in PpLog. 

More specifically, well-modedness for PpLog programs extends the same notion for logic programs, 
introduced in [7]: A mode for the relation • : : • ==>• is a function that defines the input and output 
positions of the relation respectively as in{- : : • ==>•) = {1,2} and out(- : : ■ ==>•) = {3}. A mode is 
defined (uniquely) for a Prolog relation as well. A clause is moded if all its predicate symbols are moded. 
We assume that all p -clauses are moded. As for the Prolog clauses, we require modedness only for those 
ones that define a predicate that occurs in the body of some p -clause. If a Prolog literal occurs in a query 
in conjunction with a p -clause, then its relation and the clauses that define this relation are also assumed 
to be moded. 

Before defining well-modedness, we introduce the notation vars(E) for a set of variables occurring 
in an expression E, and define vars(E, {p\ ,...,/?„}) = U" =l vars(E\ Pi ), where E\ Pi is the standard notation 
for a subexpression of E at position p\. The symbol stands for the set of anonymous variables. A 
ground expression contains no variables. Then well-modedness of queries and clauses are defined as 
follows: 

Definition 1 A query L i , . . . , L n is well-moded iff it satisfies the following conditions for each 1 < i < n: 

• vars(Li,/«(Li)) <ZU'jl} l vars(Lj,out(Lj))\'f 3ri . 

• IfL± is a negative literal, then vars (L i; out (Li)) C VJ'7}\ vars {^i , out (Lj)) U Y 3n . 

• IfL± is a pLog literal, then its strategy term is ground. 

A clause Lo : -Li , . . . , L n is well-moded, iff the following conditions are satisfied for each 1 < i < n: 

• vars(Li,in(L±)) U vars (L , out (L )) C U'jZ} Q vars(Lj,out(Lj)) \ Y 3n . 

• If L± is a negative literal, then vars (L±, out (L±)) C U^r ^ vars (Lj ,ow?(Lj )) U U vars (Lq, in (Lo)). 

• IfL and L ± are pLog literals with the strategy terms st and st i; respectively, then vars(st±) C 
vars(sto). 

PpLog allows only well-moded program clauses and queries. There is no restriction on the Prolog 
clauses if the predicate they define is not used in a p -clause. 
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Example 2 The query strl :: a ==> i_X, str2 :: i_Y ==> i_Z is not well-moded, because the 
variable i_Y in the input position of the second subgoal does not occur in the output position of the first 
subgoal. On the other hand, strl :: a ==> i_X, str2 :: i_X ==> i_Z is well-moded. 

If we change the last goal into strl :: a ==> i_X, str2 :: i_X =\=> i_Z, well-modedness 
will get violated again, because the variable i_Z, occurring in the negative literal, does not appear in 
the output position of the previous subgoal. Examples of well-moded queries involving negative liter- 
als are, e.g., strl :: a ==> (i_X, i_Z) , str2 :: i_X =\=> i_Z and strl :: a ==> i_X, 
str2 : : i_X =\=> i_. 

For well-moded programs and queries, PpLog uses Prolog's depth-first inference mechanism with 
the leftmost literal selection in the goal. If the selected literal is a Prolog literal, then it is evaluated in 
the standard way. If it is a p-atom of the form st : : hi ==> h2, then PpLog finds a (renamed copy of 
a) program clause st ' : : hi' ==> h2' : - body such that st' matches st and hi' matches hi with 
a substitution a. Then, it replaces the selected literal in the query with the conjunction of bodya and a 
literal that forces matching h.2 to h2'a, applies a to the rest of the query, and continues. Success and 
failure are defined in the standard way. Backtracking allows to explore other alternatives that may come 
from matching the selected query literal to the head of the same program clause in a different way, or to 
the head of another program clause. 

Negative p -literals are processed by the standard negation-as-failure rule: A negative query of the 
form str : : hi =\=> h2 succeeds if all attempts of satisfying its complementary literal, a positive 
query str : : hi ==> h2, end with failure. Well-modedness guarantees that whenever such a negative 
literal is selected during the PpLog execution process, there are no variables in it except, maybe, some 
anonymous variables that may occur in h2. 

4 Strategic Programming in PpLog 

Strategies can be combined to express in a compact way many tedious small step transformations. These 
combinations give more control on transformations. PpLog provides a library of several predefined 
strategy combinators. Most of them are standard. The user can write her own strategies in PpLog or 
extend the Prolog code of the library. Some of the predefined strategies and their intuitive meanings are 
the following: 

• id : : hi ==> h2 succeeds if the hedges hi and h.2 are identical (or can be made identical by h.2 
matching hi) and fails otherwise. 

• compose(sti, st 2 , . . . , st n ), n>2, first transforms the input hedge by sti and then transforms 
the result by compose(st 2 , . . . , st n ) (or by st 2 , if n = 2). Via backtracking, all possible results 
can be obtained. The strategy fails if either sti or compose(st 2 , . . . , st n ) fails. 

• choice(sti, . . . , st n ), n > 1, returns a result of a successful application of some strategy sti to 
the input hedge. It fails if all sti's fail. By backtracking it can return all outputs of the applications 
of each of the strategies sti, ... , st n . 

• f irst_one(sti, . . . , st n ), n > 1, selects the first sti that does not fail on the input hedge and re- 
turns only one result of its application, f irst_one fails if all sti's fail. Its variation, f irst_all, 
returns via backtracking all the results of the application to the input hedge of the first strategy sti 
that does not fail. 
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• nf (st), when terminates, computes a normal form of the input hedge with respect to st. It never 
fails because if an application of st to a hedge fails, then nf (st) returns that hedge itself. Back- 
tracking returns all normal forms. 

• iterate(st,7Y) starts transforming the input hedge with st and returns a result (via backtracking 
all the results) obtained after /V iterations for a given natural number N. 

• mapl(st) maps the strategy st to each term in the input hedge and returns the result hedge. Back- 
tracking generates all possible output hedges, st should operate on a single term and not on an 
arbitrary hedge, mapl(st) fails if st fails on at least one term from the input hedge, map is a vari- 
ation of mapl where the single-term restriction is removed. It should be used with care because 
of high nondeterminism. Both mapl and map, when applied to the empty hedge, return the empty 
hedge. 

• interactive takes a strategy from the user, transforms the input hedge by it and waits for further 
user instruction (either to apply another strategy to the result hedge or to finish). 

• rewrite(st) applies to a single term (not to an arbitrary hedge) and rewrites it by st (which also 
applies to a single term). Via backtracking, it is possible to obtain all the rewrites. The input term 
is traversed in the leftmost-outermost manner. Note that rewrite(st) can be easily implemented 
inside PpLog: 

rewrite (i_Str) :: c_Context (i_Redex) ==> c_Context (i_Contractum) :- 
i_Str : : i_Redex ==> i_Contractum. 

We give below few examples that demonstrate the use some of the PpLog features, including the 
strategies we just mentioned. The users can define own strategies in a program either by writing clauses 
for them or using abbreviations of the form str_ 1 : = str_2. Such an abbreviation stands for the clause 
str_l :: s_X ==> s_Y :- str_2 :: s_X ==> s_Y. 

Example 3 Let strl and str2 be two strategies defined as follows: 

strl :: (s_l, a, s_2) ==> (s_l, f(a), s_2) . 

str2 :: (s_l, i_x, s_2, i_x, s_3) ==> (s_l, i_x, s_2, s_3) . 

Putting different strategies in the goal we get different answers: 

• The goal strl :: (a, b, a, f(a)) ==> s_X returns two answers (instantiations of the se- 
quence variable s_X): (f (a) , b, a, f (a) ) and (a, b, f(a), f (a)) . Multiple answers are 
computed by backtracking. They are two because (s_l , a, s_2) matches (a, b, a, f (a)) in 
two ways, with the matchers {s_li— >-eps, s_2i— Kb , a, f (a) ) } and {s_li— Ka, b), s_2i— >f (a) }, 
respectively. 

• If 'we change the previous goal into strl :: (a, b, a, f(a)) ==> (s_X, f (a) , s_Y), then 
PpLog will return four answers that correspond to the following instantiations ofs_X and s_Y: 

1. s_Xi->eps, s_Yi-Kb, a, f(a)). 

2. s_Xi-Kf(a), b, a), s_Yi->eps. 

3. s_X^(a, b), s_Yh^f (a). 

4. s_Xi-Ka, b, f (a)), s_Yi-^eps. 

• The goal strl : : (a, b, a, f (a)) =\=> s_ fails, because it's positive counterpart suc- 
ceeds. On the other hand, strl :: (a, b, a, f(a)) =\=> (b, s_) succeeds. 
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• The composition compose (strl , str2) :: (a, b, a, f(a)) ==> s_X gives two answers: 
(f(a), b, a) and (a, b, f(a)), 

• On the goal choice (strl , str2) :: (a, b, a, f(a)) ==> s.Xwe get three hedges as an- 
swers: (f (a) , b, a, f (a)), (a, b, f(a), f (a) ), and (a, b, f(a)). 

• nf (compose (strl , str2)) :: (a, b, a, f(a)) ==> s _X, which computes a normal form 
of the composition, returns (f (a) , b) twice, computing it in two different ways. 

• The goal first_one (strl , str2) :: (a, b, a, f(a)) ==> s_X returns only one answer 
(f(a), b, a, f(a)) . This is the first output computed by the first applicable strategy, strl. 

• Finally, f irst_all (strl , str2) :: (a, b, a, f(a)) ==> s_X computes two instantia- 
tions: (f(a), b, a, f(a)) and (a, b, f(a), f(a)). These are all the answers returned 
by the first applicable strategy, strl. 

Example 4 The two PpLog clauses below flatten nested occurrences of the head function symbol of a 
term. The code is written using function and sequence variables, which makes it reusable, since it can 
be used to flatten terms with different heads and different numbers of arguments: 

flatten_one :: f_Head(s_l, f _Head(s_2) , s_3) ==> f_Head(s_l, s_2, s_3) . 
flatten := nf (f latten_one) . 

The first clause flattens one occurrence of the nested head. The second one ( written in the abbreviated 
form) defines the flatten strategy as the normal form of f latten_one. Here are some examples of 
queries involving these strategies: 

• flatten_one :: f(a, f(b, f(c)), f(d)) ==> i_X g/ves f (a, b, f(c), f(d)). 

• flatten :: f(a, f(b, f(c)), f(d)) ==> i_X returns f (a, b, c, d). 

• We can map the strategy flatten to a hedge, which results in flattening each element of the hedge. 
For instance, the goal mapl (flatten) :: (a, f(f(a)), g(a, g(b))) ==> s _X returns the 
hedge (a, f(a), g(a, b)). 

Example 5 The replace strategy takes a term and a sequence of replacement rules, chooses a subterm 
in the given term that can be replaced by a rule, and returns the result of the replacement. replace_all 
computes a normal form with respect to the given replacement rules. 

replace :: (c_Context (i_X) , s_l, i_X -> i_Y, s_2) ==> 
(c_Context(i_Y) , s_l, i_X -> i_Y, s_2) . 

replace_all :: (i_Term, s_Rules) ==> i_Instance :- 

nf (replace) :: (i_Term, s_Rules) ==> (i_Instance, s_) . 

With replace_all, one can, for example, compute an instance of a term under an idempotent substi- 
tution: replace_all :: (f(x, g(x, y)), x -> z, y -> a) ==> i_X gives f(z, g(z, a)). 
(We can take the conjunction of this goal with the cut predicate to avoid recomputing the same instance 
several times.) The same code can be used to compute a normal form of a term under a ground rewrite 
system, the sort of a term if the rules are sorting rules, etc. 

Example 6 This is a bit longer example that shows how one can specify a simple propositional proving 
procedure in PpLog. We assume that the propositional formulas are built over negation (denoted by '-') 
and disjunction (denoted by V). The corresponding PpLog program starts with the Prolog operator 
declaration that declares disjunction an infix operator: 
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:- op(200, xfy, v) . 

Next, we describe inference rules of a Gentzen-like sequent calculus for propositional logic. The 
rules operate on sequents, represented as sequent (ant (sequence of formulas) , cons (sequence of 
formulas)), ant and cons are tags for the antecedent and consequent, respectively. There are five infer- 
ence rules in the calculus: The axiom rule, negation left, negation right, disjunction left, and disjunction 
right. 

axiom :: sequent (ant (s_ , i_Formula, s_) , cons(s_, i_Formula, s_)) ==> eps. 

neg_left :: sequent (ant (s_Fl , - (i_Formula) , s_F2) , cons(s_F3)) ==> 
sequent (ant (s_Fl , s_F2) , cons (i_Formula, s_F3)). 

neg_right :: sequent (ant (s_Fl) , cons(s_F2, - (i_Formula) , s_F3)) ==> 
sequent (ant (s_Fl , i_Formula) , cons(s_F2, s_F3)). 

disj_left :: sequent (ant (s_Fl , i_Formulal v i_Formula2, s_F2) , i_Cons) ==> 
(sequent (ant (s_Fl , i_Formulal , s_F2) , i_Cons) , 
sequent (ant (s_Fl , i_Formula2, s_F2) , i_Cons)). 

disj_right :: sequent (i_ant , cons(s_Fl, i_Formulal v i_Formula2, s_F2)) ==> 
sequent (i_ant , cons(s_Fl, i_Formulal , i_Formula2, s_F2)). 

Next, we need to impose control on the applications of the inference rules and define success and 
failure of the procedure. The control is pretty straightforward: To perform an inference step on a given 
hedge of sequents, we select the first sequent and apply to it the first applicable inference rule, in the 
order specified in the arguments of the strategy f irst_one below. When there are no sequents left, the 
procedure ends with success. Otherwise, if no inference step can be made, we have failure. 

success :: eps ==> true. 

inf erence_step :: (sequent (i_Ant , i_Cons) , s_Sequents) ==> 
(s_New_sequents , s_Sequents) :- 
first_one (axiom, neg_left, neg_right, disj_left, disj_right) :: 
sequent (i_Ant , i_Cons) ==> s_New_sequents . 

failure :: (sequent (i_Ant , i_Cons) , s_Sequents) ==> false. 

Finally, we specify the proof procedure as repeatedly applying the first possible strategy between 
success, inf erence_step, and failure (in this order) until none of them is applicable: 

prove := nf (first_one (success , inf erence_step , failure)). 

Note that it does matter in which order we put the clauses for the inference rules or the control in the 
program. What matters, is the order they are combined (e.g. as it is done in the strategy f irst_onej. 

What we described here is just one way of implementing the given propositional proof procedure in 
PpLog. One could do it differently as well, for instance, by writing recursive clauses like it has been 
shown in [14 ]. However, we believe that the version above is more declarative and naturally corresponds 
to the way the procedure is described in textbooks. 
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Note that there can be several clauses for the same strategy in a PpLog program. In this case they 
behave as usual alternatives of each other (when a query with this strategy is being evaluated) and are 
tried in the order of their appearance in the program, top-down. 

5 Implementing Rewriting Strategies 

In this section we illustrate how rewriting strategies can be implemented in PpLog. It can be done in a 
pretty succinct and declarative way. The code for leftmost-outermost and outermost rewriting is shorter 
than the one for leftmost-innermost and innermost rewriting, because it takes an advantage of PpLog's 
built-in term traversal strategy. 

Leftmost-Outermost and Outermost Rewriting. As mentioned above, the rewrite strategy tra- 
verses a term in leftmost-outermost order to rewrite subterms. For instance, if the strategy strat is 
defined by two rules 

strat :: f(i_X) ==> g(i_X) . 
strat :: f(f(i_X)) ==> i_X. 

then for the goal rewrite (strat) :: h(f(f(a)), f(a)) ==> i_X we get, via backtracking, four 
instantiations for i_X, in this order: h(g(f(a)), f(a)), h(a, f(a)), h(f(g(a)), f(a)),and 
h(f(f(a)), g(a)). 

If we want to obtain only one result, then it is enough to add the cut predicate at the end of the goal: 
rewrite (strat) :: h(f(f(a)), f(a)) ==> i_X, ! returns only h(g(f (a) ) , f(a)). 

To get all the results of leftmost-outermost rewriting, we have to find the first redex and rewrite it in 
all possible ways (via backtracking), ignoring all the other redexes. This can be achieved by using an 
anonymous variable for checking reducibility, and then putting the cut predicate: 

rewrite_lef t_out (i_Str) :: c_Context (i_Redex) ==> c_Context (i_Contractum) :- 
i_Str :: i_Redex ==> i_, 
i 

• > 

i_Str : : i_Redex ==> i_Contractum. 

The goal rewrite_left_out (strat) :: h(f(f(a)), f(a)) ==> i_X gives two instantiations 
for i_X: h(g(f (a)) , f (a) ) and h(a, f(a)). 

To return all the results of outermost rewriting we find an outermost redex and rewrite it. Backtrack- 
ing returns all the results for all outermost redexes. 

rewrite_out (i_Str) :: i_X ==> i_Y :- 
i_Str : : i_X ==> i_, 

• > 

i_Str : : i_X ==> i_Y. 

rewrite_out(i_Str) :: f_F(s_l, i_X, s_2) ==> f_F(s_l, i_Y, s_2) :- 
rewrite_out (i_Str) :: i_X ==> i_Y. 

The goal rewrite_out (strat) : : h(f (f (a)), f (a)) ==> i_X gives three answers, in this 
order: h(g(f (a)), f(a)), h(a, f (a) ) , and h(f (f (a) ) , g(a)). 
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Leftmost-Innermost and Innermost Rewriting. Implementation of innermost strategy in PpLog is 
slightly more involved than the implementation of outermost rewriting. It is not surprising since the out- 
ermost strategy takes an advantage of the PpLog built-in term traversal strategy. For innermost rewriting, 
we could have modified the PpLog source by simply changing the order of two rules in the matching 
algorithm to give preference to the rule that descends deep in the term structure. It would change the 
term traversal strategy from leftmost-outermost to leftmost-innermost. Another way would be to build 
term traversal strategies into PpLog (like it is done in ELAN and Stratego, for instance) that would give 
the user more control on traversal strategies, giving her a possibility to specify the needed traversal inside 
a PpLog program. 

However, here our aim is different: We would like to demonstrate that rewriting strategies can be 
implemented quite easily inside PpLog. For the outermost strategy it has already been shown. As for the 
innermost rewriting, if we want to obtain only one result by leftmost-innermost strategy, we first check 
whether any argument of the selected subterm rewrites. If not, we try to rewrite the subterm and if we 
succeed, we cut the alternatives. The way how matching is done guarantees that the leftmost possible 
redex is taken: 

rewrite_lef t_in_one(i_Str) :: c_Ctx(f _F(s_Args) ) ==> c_Ctx(i_Contractum) :- 
rewrites_at_least_one (i_Str) :: s_Args =\=> i_, 
i_Str : : f_F(s_Args) ==> i_Contractum, 
! . 

rewrites_at_least_one(i_Str) :: (s_, i_X, s_) ==> true :- 
rewrite (i_Str) :: i_X ==> i_, 
! . 

To get all results of leftmost-innermost rewriting, we first check whether the selected subterm is an 
innermost redex. If yes, the other redexes are cut off and the selected one is rewritten in all possible 
ways: 

rewrite_lef t_in(i_Str) :: c_Context (f _F(s_Args) ) ==> 

c_Context (i_Contractum) :- 
rewrites_at_least_one (i_Str) : : s_Args =\=> i_, 
i_Str :: f_F(s_Args) ==> i_, 
i 

■ > 

i_Str : : f_F(s_Args) ==> i_Contractum. 

If strat is the strategy defined in the previous section, then we have only one answer for the goal 
rewrite_left_in(strat) :: h(f(f(a)), f(a)) ==> i_X: the term h(f (g(a) ) , f(a)). The 
same term is returned by rewrite_lef t_in_one. 

Finally, rewrite_in computes all results of innermost rewriting via backtracking: 

rewrite_in(i_Str) :: f_F(s_Args) ==> i_Y :- 

rewrites_at_least_one (i_Str) :: s_Args =\=> i_, 
i_Str :: f_F(s_Args) ==> i_Y. 

rewrite_in(i_Str) :: f_F(s_l, i_X, s_2) ==> f_F(s_l, i_Y, s_2) :- 
rewrite_in(i_Str) : : i_X ==> i_Y. 

The goal rewrite_in(strat) :: h(f(f(a)), f(a)) ==> i_X returns two instantiations of i_X: 
h(f(g(a)), f (a)) andh(f (f (a)) , g(a)). 
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6 Concluding Remarks 

PpLog extends Prolog with strategic conditional transformation rules that operate on hedges. The rules, 
written as clauses in PpLog programs, define strategies. Strategy combinators help the user to construct 
more complex strategies from simpler ones. PpLog queries may have several results. They can be 
explored by backtracking. Four different kinds of variables used in PpLog make the system expressive 
and flexible. 

PpLog is based on Prolog's inference mechanism and allows Prolog clauses and predicates in its 
programs. The users familiar with logic programming and Prolog can very quickly start using PpLog 
since its syntax is similar to that of Prolog and semantics is based on logic programming. 

We gave a brief overview on strategies in PpLog, explained some of them on examples, and showed 
how rewriting strategies can be compactly and declaratively implemented. PpLog is written in SWI- 
Prolog ifTTl and has been tested for versions 5.6.50 and later. It is available for downloading from 
http : //www . rise . uni-linz . ac . at/people/tkutsia/sof tware . html. 
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